+1, I was going to propose the same thing. If we allow runtime values for the lengths of the subslices, and add support for multiple mut ref borrows inside an array pattern (which we should do anyway), then our language support for safely manipulating mutable arrays will be completely first-class, and current unsafely implemented functions like mut_split_at will become redundant.

(I'm not entirely sold on the syntax, but I think your idea is better than anything I came up with.)

cc @jakub-

-1. I think I'd actually be in favour of removing them altogether or reducing them to only the simplest cases ([a, b, c, ..tail]).

To elaborate, they're making the pattern sanity check pass much more complicated than it really needs to be and add significant disconnect between that pass and the codegen for patterns. I think I'd also agree they also don't fit well with the other patterns that only cover ADTs, which vectors are not.

Is it even possible to check exhaustiveness and redundancy of these kinds of patterns?

I think it would have to be conservative, i.e. if the compiler can't prove exhaustiveness, require a wildcard pattern.

@zwarich
I don't see why checking exhaustiveness would be problematic in these kind of patterns. Remember that they are all fixed-sized, so they cannot match more than something like [_,_,_], which is allowed today.

Sorry, I totally missed the fixed-size qualification.

It depends on whether you allow the fixed sizes to be runtime values. If you do, my answer applies. If you don't, @krdln's does. I think.

Edit: Hm, I see now that runtime values for the fixed sizes was never mentioned in the OP. Mea culpa. I misinterpreted the unresolved question section.

@nick29581

#101 - Allow multiple (fixed-size) subslices borrows in one pattern - krdln
Allows matching several parts of a vec in one pattern. Adds xs..n syntax to match a fixed size slice (and changes variable sized slice pattern syntax to xs.. from ..xs).
Not much feedback - all positive or corrected later to be positive. Seems like a small generalisation with no downsides.
If we change the syntax as recommended for existing patterns (i.e., ..xs to xs..) then the rest should be backwards compatible, I think.

FWIW, I think this syntax change makes some logical sense on its own terms.

We currently use the syntax ..FOO in a number of places to mean various vaguely similar but different things. The idea here would be to add a bit more distinction, so that FOO.. means "these things", for instance in slice patterns and functional struct updates, while ..FOO means "this many things", e.g. in fixed-length arrays and element-replication for same.

And then as a side benefit, it becomes possible to have both of them where the cases overlap, as with the fixed-length slice patterns in this proposal.

+1 I like this. At the very least, I think we should change ..xs to xs.. as I find it clearer and more logical, and it would allow the rest to be implemented at a later date if it isn't accepted, now.

This was discussed at this week's Rust meeting (https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-08-12.md). We decided that we don't want to implement these changes in full, in particular that enhancing slice matching is something we are a little bit uncomfortable with and needs some thought and planning but is low enough priority that we don't want to do that before 1.0.

However, we are sympathetic to leaving this option open in the future, so we would like to make the change to slice syntax (the position of ..). @krdln would you like to submit a new, cut down version of this RFC with just the syntactic changes required to make the rest of this RFC backwards compatible? If you would prefer not to, then I'm happy to do it too, just let me know.

Thanks for the RFC!

I'm happy to hear that there's a slight possibility that my RFC might be accepted in a far future!
And I will be happy to write new RFC consisting of only .. change. Will try to do it today.

Edit: Here it is: #202